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ABSTRACT 


Subscribers  of  the  Defense  Data  Network  (DDN)  will  be  responsi¬ 
ble  for  interfacing  their  host  systems  and  terminals  to  the  netvork. 
This  Guide  describes  the  methods  of  interconnection  that  are  avail¬ 
able  to  DDN  subscribers  and  the  strategies  to  obtain  these  inter¬ 
faces.  The  Guide  also  describes  the  communications  technology  used 
by  the  DDN  and  provides  a  sumnary  of  the  services  offered  by  the  net¬ 
work  as  well  as  the  protocols  that  support  these  services.  Appendix 
A  is  a  detailed  interface  specification  which  could  be  included  in 
subscriber  interface  acquisition  packages. 
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1 .0  INTRODUCTION 


All  currently  operational  and  planned  automatic  data  processing 
systems  and  data  networks  of  the  Department  of  Defense  (DoD)  that 
require  long-haul  and  area  data  communications  support  are  slated  to 
become  subscribers  to  the  Defense  Data  Network  (DDN)  as  required  by 
the  Office  of  the  Secretary  of  Defense^!).  The  term  "subscriber" 
refers  not  only  to  systems  but  also  to  those  individuals  with  the 
managerial  and  technical  responsibilities  for  the  systems.  Since  the 
advent  of  the  DDN,  this  group  of  action  officers,  managers,  and  sys¬ 
tems  analysts  has  been  faced  with  the  issue  of  how  to  connect  their 
systems  to  the.  DDN.  .This  Guide  has  been  prepared  to  assist  these 
decision-makers . 

The  Guide  will  explain  the  available  alternatives  for  connecting 
systems  to  the  DDN  and  the  rationale  for  choosing  among  them.  The 
selection  options  are  based  upon  the  communication  requirements  of 
the  subscriber  and  the  interfacing  methods  that  will  support  these 
requirements.  " 

The  Guide  is  organized  to  facilitate  the  decision-making  pro¬ 
cess.  The  reader  is  introduced  to  the  DDN  in  Sections  2  and  3  with  a 
subscriber's  perspective  of  its  services  and  protocol  architecture. 
With  this  foundation,  the  reader  can  proceed  to  Section  4  for  a  dis¬ 
cussion  of  interfacing  strategies  and  to  Section  5  for  a  summary  of 
how  to  acquire  these  interfaces.  Section  6  provides  p  summary  of  the 

->  J-  ft  ■  iv»-  ,  J  .  * 

information  presented  in  the  Guide.  Finally,  Appendix  A  provides  a 
detailed  interface  specification  that  could  be  included  in  subscriber 
interface  acquisition  packages. 

Further  information  can  be  obtained  by  directly  contacting  the 
DDN  Program  Management  Office  (PMO)  of  the  Defense  Communications 
Agency  (DCA).  The  DDN  PMO  has  published  an  information  brochure  that 
discusses  the  entire  DDN  program. 
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2.0  DDN  COMMUNICATION  CONCEPTS 


DoD  data  communication  requirements  are  expanding  rapidly.  The 
purpose  of  the  DDN  is  to  meet  these  requirements.  Packet  switching 
technology  developed  for  the  Advanced  Research  Projects  Agency  Net¬ 
work  (ARPANET)  enables  the  DDN  to  achieve  this  purpose  with  a  high 
degree  of  economy  and  performance.  Over  the  past  decade ,  the  ARPANET 
has  provided  a  research  and  development  environment  for  state-of- 
the-art  techniques  in  data  communications.  The  DDN  is  a  direct  bene¬ 
ficiary  of  the  ARPANET  accomplishments.  The  DDR  is  employing  ARPANET 
technology  and  in  fact  is  subsuming  a  major  portion  of  the  existing 
ARPANET  as  well  as  other  military  networks  that  use  ARPANET  technol¬ 
ogy. 

The  coiuninications  services  that  the  ARPANET  has  been  providing 
since  the  late  sixties  are  significant  because  they  enable  computer 
systems  from  different  vendors  with  different  operating  systems  to 
exchange  data.  The  data  can  be  files,  programs,  or  electronic  mail. 
This  type  of  communication  is  known  as  heterogeneous  host-to-hoat 
corns tunication.  The  vehicle  for  providing  heterogeneous  host-to-host 
comaunication  is  a  layered  protocol  architecture.  Vendor-specific 
protocol  architectures  such  as  Digital  Equipment  Corporation's  DECNET 
and  IBM's  SNA  provide  similar  services  for  a  particular  vendor's  pro¬ 
duct  line,  or  hosiogeneoua  communication. 

The  advantage  offered  to  DDN  subscribers  by  a  protocol  architec¬ 
ture  that  supports  heterogeneous  communication  is  significant;  a  very 
diverse  group  of  users  and  their  software  systems  can  interoperate. 
Such  interoperability  ensures  that  critical  DoD  systems  will  be  able 
to  communicate  with  one  another  in  the  future,  even  if  the  require¬ 
ment  to  do  so  is  not  now  anticipated. 

Recently,  after  years  of  design,  implementation,  and  testing 
funded  by  the  Defense  Advanced  Research  Projects  Agency,  the  ARPANET 
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protocol  hierarchy  was  enhanced.  The  enhancements  broadened  the 
scope  of  the  architecture  to  include  multiple  interconnected  net¬ 
works.  In  extending  the  architecture  to  span  network  boundaries,  no 
assumptions  were  made  about  the  underlying  comaunications  technology 
of  each  individual  network.  This  permits  subscribers  with  networks 
using  different  technologies,  such  as  local  area  networks,  to  intero¬ 
perate  with  ARPANET  subscribers.  Successful  interoperation  of  many 
different  types  of  networks  has  been  demonstrated,  and  the  architec¬ 
ture  has  been  operational  since  1  January  1983. 

The  DDN  is  using  this  protocol  architecture  for  its  DoD  sub¬ 
scribers.  The  enhancements  are  embodied  in  the  Transmission  Control 
Protocol  (TCP)  and  the  Internet  Protocol  (IP),  which  are  DoD  stan¬ 
dards.  As  DoD  standards,  these  protocols  form  the  basis  for  ongoing 
security  research  and  development  efforts  which,  over  time,  will  be 
incorporated  into  the  DDN  without  impacting  subscribers. 

The  DDN  protocol  suite  provides  a  set  of  interoperable  sub¬ 
scriber  services.  In  the  research  comnunity,  all  subscribers  imple¬ 
mented  the  complete  protocol  suite;  therefore,  all  ARPANET  sub¬ 
scribers  could  comunicate  with  all  other  ARPANET  subscribers.  Since 
the  DDN  subscriber  community  is  vast,  vith  an  accompanying  set  of 
unique  requirements,  waiver  procedures  have  been  established  to  per¬ 
mit  subscribers  to  utilise  the  DDN  even  though  they  may  not  have 
implemented  all  the  required  DoD  standard  protocols  at  connection 
time.  However,  it  is  incumbent  on  all  subscribers  (and  also  to  their 
benefit)  to  implement  the  full  DDN  protocol  suite  in  a  timely  manner. 

Over  the  short  term,  subscribers  may  use  the  DDN  as  a  "wire- 
replacement"  for  existing  hard-wired  or  leased-line  connections.  The 
DDN  is  funding  a  hardware  and  software  development  that  will  allow 
computer  systems  to  access  the  DDN  using  the  X.25  international  pro¬ 
tocol  standard.  Thus,  subscribers  will  be  able  to  preserve  their 
existing  investments  in  applications  specifically  dependent  on  X.25 


and  to  use  the  DDN  as  a  wire-replacement  while  they  are  developing 
implementations  of  the  DDN  protocol  suite. 


X.25  is  only  the  base  network  access  component  of  a  yet  to  be 
developed  international  protocol  suite.  It  will  be  many  years  before 
a  full  international  protocol  suite  is  adopted.  The  DDN  X.25 
development  facilitates  a  dual  implementation  strategy  -  the  DDN 
suite  on  one  hand  and  vendor-specific  protocols  on  the  other,  both 
sitting  atop  X.25  -  that  will  allow  a  graceful  evolution  when  the 
international  protocols  mature.  However,  it  is  important  to  note 
that  security  requirements  may  prevent  certain  conaunities  from  mak¬ 
ing  this  transition. 


3.0  DIM  SERVICES  AND  PROTOCOLS 


Subscribers  are  responsible  for  selecting  interfaces  to  the  DDN. 
In  order  to  make  their  selections,  they  need  to  understand  the  ser¬ 
vices  offered  by  the  DDN  and  the  relationship  betveen  the  DDN  ser¬ 
vices  and  the  DIR)  protocols. 

The  DDN  protocols,  as  illustrated  in  Figure  1,  are  organised 
into  a  hierarchical  architecture.  The  protocols  at  each  level  of  the 
hierarchy  provide  certain  services  to  higher  level  protocols  or  to 
users,  and  utilise  the  services  provided  by  lover  level  protocols. 
At  the  top  of  the  hierarchy  are  the  application  protocols,  which  sup¬ 
port  specific  user  requirements.  Beneath  the  application  protocols 
are  TCP  and  IP,  vbich  together  provide  a  reliable  data  communication 
service  between  processes  in  hosts  on  the  DDN  or  on  other  TCP/IP  net¬ 
works  connected  to  the  DDN.  A  host  is  a  subscriber  computer  system 
or  other  computing  device  such  as  a  TAC  or  mini-TAC,  which  are 
described  in  Section  4  of  this  Guide.  At  the  bottom  of  the  hierarchy 
are  two  sets  of  network  access  protocols,  the  ARPANET  network  access 
protocols  and  X.25,  which  comprise  the  two  host-to-netvork  interfaces 
that  are  supported  by  the  DIR). 

The  application,  host-to-boat,  and  netvork  access  protocols  and 
their  associated  services  are  described  in  more  detail  in  the  follow¬ 
ing  subsections.  The  protocols  are  formally  specified,  largely  by 
reference  to  other  specification  documents,  in  Appendix  A.  Copies  of 
many  of  the  referenced  documents  appear  in  the  Internet  Transition 
Workbook  (2) . 

3.1  Application  Services  and  Protocols 

As  shovn  in  Figure  1 ,  a  number  of  protocols  may  be  required  to 
satisfy  the  subscriber's  networking  application  requirements.  The 
ARPANET  TELNET  protocol.  File  Transfer  Protocol  (FTP),  and  Simple 
Mail  Transfer  Protocol  (SMTP)  are  the  standard  DDN  application  proto- 
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cols.  They  support  scroll  mode  terminal-to-host  communication,  file 
transfer  service,  and  electronic  mail  service.  "Native  Mode"  is  not  a 
standard  DDN  protocol,  but  rather  a  standard  way  of  referring  to  the 
existing  variety  of  terminal-specific  (e.g.,  IBM  3270)  protocols, 
each  of  which  supports  communication  between  synchronous  terminals  of 
a  specific  class  and  their  compatible,  or  native,  hosts.  It  is 
recommended  that  each  subscriber  host  implement  TELNET,  FTP,  SMTP, 
and  the  applicable  Native  Mode  protocol. 

In  addition  to  the  application  protocol  implementations,  the 
subscriber  must  acquire  application  programs  that  provide  user  inter¬ 
faces  (and  in  the  case  ot  tile  transfer  and  mail,  local  file  system 
interfaces)  to  the  application  protocols.  The  user  interface  por¬ 
tions  of  these  application  programs  are  not  standardized,  and  the 
specification  of  their  functionality  is  completely  the  user's,  respon¬ 
sibility. 

Although  TELNET,  FTP,  SMTP,  and  Native  Mode  are  the  typical 
users  of  TCP,  vendors  are  free  to  develop  new  TCP-based  application 
protocols,  which  DDN  subscribers  may  then  utilize.  Also,  DDN  sub¬ 
scribers  may  develop,  or  have  developed  for  them,  additional  applica¬ 
tion  protocols  to  meet  their  unique  requirements. 

3.1.1  Terminal-to-Ho8t  Communication  Service 

The  TELNET  protocol  facilitates  communication  between  hosts  and 
terminals  from  different  vendors.  The  TELNET  protocol  provides  a 
standard  view  of  a  network  terminal,  i.e.,  a  "virtual  terminal."  The 
standard  virtual  terminal  is  an  asynchronous  ASCII  terminal  operating 
in  scroll  mode.  The  TELNET  protocol  also  provides  a  method  of  nego¬ 
tiating  options  above  the  standard  virtual  terminal.  The  negotiated 
virtual  terminal  exists  for  the  duration  of  the  session  between  the 


When  TELNET  and  its  supporting  protocols  are  implemented  and  in 
use,  the  terminal  user  has  the  impression  that  he  or  she  is  logged  on 
to  a  host  that  is  directly  connected  to  the  terminal.  The  user  may 
execute  all  tasks  normally  possible  on  that  host,  including  logging 
in,  editing,  compiling,  running  application  programs,  manipulating 
files,  etc.  The  TELNET  protocol,  in  the  meantime,  is  handling  the 
conversions  necessary  for  host-terminal  compatibility. 

3.1.2  File  Transfer  Service 

File-related  activities  such  as  copying,  appending,  deleting  and 
renaming  are  comnon  requirements  of  network  users.  They  may  be  car¬ 
ried  out  both  under  the  direction  of  a  terminal  user  or  under  the 
direction  of  an  application  program.  Subscribers  of  the  DDN  may  use 
the  network  and  the  standard  File  Transfer  Protocol  to  direct  the 
transfer  of  data  files  between  network  hosts  and  to  access  other  file 
management  services. 

FTP  implementations  are  integrated  with  a  host's  file  management 
system  to  provide  the  following  common  network  capabilities: 

o  access  to  both  the  source  and  destination  file  management 
systems  -  in  effect,  simultaneous  log-ins; 

o  transformation  between  source  and  destination  file  formats; 

o  directing  the  transfer  of  large  volumes  of  data  in  the  pres¬ 
ence  of  potential  network  failures,  and 

o  providing  other  file  manipulation  functions  such  as  direc¬ 
tory  listings,  appending,  deleting,  etc. 

3.1.3  Electronic  Mail  Service 

The  ARPANET  Simple  Mail  Transfer  Protocol  supports  electronic 
message  transfers  over  the  DDN.  The  SMTP  is  implemented  on  hosts 
that  support  user  "mailboxes''  -  file  spaces  into  which  messages  may 
be  written  and  later  read  by  the  owner.  The  SMTP  is  essentially  a 
"file  transfer"  protocol  optimized  for  message  transfer.  Electronic 


mail  service  will  be  provided  for  many  DDN  users  in  designated  "mail 
host 8."  These  will  be  hosts  supporting  message  sending,  receiving, 
and  manipulation  capabilities,  and  numerous  user  accounts. 

To  send  a  message,  the  user  logs  on  to  a  SMTP  host  and  invokes  a 
message-sending  program.  The  user  supplies  the  program  with  the  net¬ 
work  addresses  of  the  message  addressees  and  with  the  text  of  the 
message.  The  program  formats  these  items  as  a  standard  network  mes¬ 
sage  and  invokes  DDN  network  services  to  send  the  message  to  the  des¬ 
tination.  The  time  required  for  this  process  may  depend  upon  loading 
and  scheduling  of  other  jobs  in  the  sender's  host,  but  a  moderate¬ 
sized  text  message  can  often  be  processed  in  only  a  few  minutes.  The 
receiver  may  depend  upon  the  host's  operating  system  for  notification 
of  the  receipt  of  new  mail,  or  the  receiver  may  actively  check  the 
mailbox.  When  a  new  message  is  received,  the  user  invokes  the  host's 
text  manipulation  utilities  to  print  the  message  or  transfer  it  to 
another  medium,  etc. 

3.2  Data  Transport  Services  and  Protocols 

The  ARPANET  Transmission  Control  Protocol  and  its  associated 
Internet  Protocol  are  the  standard  DDN  transport  protocols.  The 
TCP/IP  protocols  provide  the  reliable  host-to-host  peer  level  commun¬ 
ication  necessary  to  support  the  application  protocols  above. 

3.2.1  Transmission  Control  Protocol 

TCP  provides  a  reliable  data  communication  service  for  interpro¬ 
cess  conmunication  over  the  DDN  and  other  TCP/IP  networks  connected 
to  the  DDN.  It  is  connection-oriented;  that  is,  it  maintains  a  con¬ 
nection,  or  virtual  circuit,  for  each  pair  of  conmunicating 
processes.  TCP  incorporates  mechanisms  to  ensure  the  reliability  of 
the  connections  and  to  control  the  flow  of  data  over  the  connections. 
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IP  transmits  and  receives  data  across  the  DDN  and  networks  con¬ 
nected  to  the  DDN.  Unlike  TCP,  it  is  connectionless;  it  treats  each 
packet  as  an  independent  entity.  Furthermore,  it  neither  checks 
users'  data  for  errors  nor  performs  flow  control.  Instead,  its  pur¬ 
pose  is  to  provide  a  means  for  communication  across  multiple  net¬ 
works.  To  this  end,  it  supports  a  global  addressing  system,  and  it 
accommodates  differences  in  maximum  packet  sizes  allowed  by  networks. 

TCP  and  TCP-based  application  protocols  are  the  typical  users  of 
IP.  However,  certain  applications  do  not  require  the  extent  of  reli¬ 
ability  provided  by  TCP  as  much  as  they  require  high  throughput  and 
low  delay.  For, example,  the  User  Datagram  Protocol  (UDP)  (3),  a  much 
simpler  protocol  than  TCP,  can  be  used  in  conjunction  with  IP  to  pro¬ 
vide  (potentially  unreliable)  interprocess  communication  across  the 
DDN  and  other  interconnected  IP  networks,  and  UDP-based  application 
protocols  can  be  developed  to  support  the  applications. 

3.3  Network  Access  Protocols 

The  network  access  protocols  define  the  interface  between  a  host 
and  the  network.  The  DDN  is  intended  to  support  two  sets  of  network 
access  protocols: 

o  the  ARPANET  network  access  protocols,  which  are  currently 
supported,  and 

o  X.25,  which  will  be  supported  beginning  in  December  1983. 

The  initial  DDN  X.25  capability  is  designed  to  support  communication 
between  hosts  that  implement  X.25.  In  mid  1984,  this  capability  will 
be  extended  to  support  interoperability  among  hosts  that  implement 
either  X.25  or  the  ARPANET  network  access  protocols. 


Although  it  is  mandatory  for  TCP  and  IP  to  reside  above  X.25  in 
all  X.25-ba8ed  host  interfaces  to  the  DDN,  other  protocols,  such  as 


4.0  SUBSCRIBER  INTERFACING  STRATEGIES 


Surveys  conducted  by  the  DDN  PMO  have  indicated  that  potential 
subscribers  plan  to  connect  a  variety  of  host  computers  and  termi¬ 
nals,  as  well  as  local  networks,  to  the  DDN.  This  section  identifies 
alternative  interfacing  strategies  available  to  DoD  managers: 

o  For  hosts: 

-  Full  service  interfaces,  or 

-  Limited  service  interfaces; 
o  For  terminals: 

-  Host  pass-through  interfaces, 

Direct  interfaces,  or 

-  Subscriber-supplied  interfaces;  and 
o  For  networks : 

-  Gateways. 

This  section  also  provides  the  guidelines  and  background  necessary 
for  subscribers  to  understand  the  different  methods  of  interconnect¬ 
ing  to  the  DDN  and  highlights  the  responsibilities  of  subscribers 
associated  with  the  interfaces  they  have  selected.  Dm  PMO  personnel 
will  assist  subscribers  in  obtaining  information  about  alternatives 
and  in  comparing  their  strengths  and  weaknesses.  Subscribers  should 
contact  the  DDN  PMO  to  request  such  assistance.  Host  interfacing 
strategies  are  discussed  first,  followed  by  a  discussion  of  terminal 
interfacing  strategies.  Although  they  are  organized  into  separate 
subsections,  the  subscriber  must  select  compatible  host  and  terminal 
interfacing  strategies  in  order  to  provide  an  effective  data  communi¬ 
cation  capability.  This  section  concludes  with  a  brief  description 
of  DDN  gateway  plans. 
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Figure  2  is  a  simple  representation  of  network  components  of  the 
DDN  illustrating  various  standard  methods  of  interfacing.  The  C/30 
is  the  component  that  serves  as  the  DDN  packet  switching  node.  The 
Internet  Private  Line  Interface  (IPLI)  is  the  security  component  that 
will  perform  end-to-end  encryption.  The  IPLI  is  being  acquired  by 
the  D1H)  PMO  and  will  be  available  to  subscribers  by  early  1985.  Due 
to  long  lead  times,  requirements  for  IPLIs  must  be  identified  four¬ 
teen  months  in  advance  of  date  of  service.  The  interfacing  methods 
and  their  associated  components  are  described  in  the  following  sub¬ 
sections. 

4.1  Hosts 

Host  interfaces  can  be  categorized  by  the  degree  of  support  pro¬ 
vided  for  network  services  and  the  method  used  to  connect  the  host 
computer  to  the  network.  The  full  service  interface  supports  al  the 
standard  DDN  protocols.  The  full  service  interface  is  the  most  ver¬ 
satile  alternative  and  is  recommended  for  host  subscribers  whenever 
feasible.  Several  architectural  arrangements  of  the  protocol  suite 
are  possible,  depending  on  subscriber  requirements  and  the  charac¬ 
teristics  of  the  host  computer  hardware  and  operating  system.  The 
selection  of  an  appropriate  strategy  that  will  provide  a  full  service 
capability  is  discussed  in  Section  4.1.1. 

Any  interface  that  does  not  support  the  full  functionality 
offered  by  the  DDN  protocol  suite  should  be  considered  a  limited  ser¬ 
vice  interface.  Limited  service  interfaces  generally  fall  into  two 
categories:  those  interfaces  supported  by  vendor-specific  suites  of 
protocols,  and  terminal  emulation  interfaces.  Either  type  of  limited 
service  interface  may  be  used  while  subscribers  are  waiting  for  the 
development  of  a  full  service  interface  for  their  host  family.  How¬ 
ever,  in  the  long  term,  the  use  of  limited  service  interfaces  should 
be  restricted  to  terminal  emulation  interfaces  for  those  systems 
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where  the  cost  of  a  full  service  interface  is  prohibitive.  Limited 
service  interfaces  are  discussed  in  Section  A. 1.2. 

4.1.1  Pull  Service  Interfaces 

Full  service  host  interfaces  implement  the  DDN  protocol  suite 
described  in  Section  3.  Use  of  the  ARPANET  application  protocols  and 
TCP/IP  is  necessary  to  achieve  interoperability  between  different 
host  types.  Beyond  this  common  use  of  the  ARPANET  protocols,  the 
characteristics  of  each  full  service  interface  are  subject  to  deci¬ 
sions  made  by  the  subscriber.  These  decisions  evolve  around  the  fol¬ 
lowing  issues: 

o  which  network  access  protocol  should  be  used,  and 

o  how  the  network  protocols,  i.e.,  host-to-host  and  network 
access,  should  be  integrated  into  the  architecture  of  the 
host  computer. 

The  first  question  can  be  resolved  fairly  easily.  The  selection 
of  a  network  access  protocol,  i.e.,  the  ARPANET  network  access  proto¬ 
cols  vs.  Z.25,  will  most  likely  be  based  on  availability  of  hardware 
and  software.  The  ARPANET  interface  is  currently  supported  in  the 
network  node,  and  prototype  or  commercial  implementations  of  the 
interface  are  available  for  some  host  families.  The  X.25  interface 
is  a  popular  commercial  interface  that  is  available  through  a  number 
of  vendors.  Upon  completion  of  the  DDN  Z.25  specification  in  Sep¬ 
tember  1983,  subscribers  may  select  Z.25  as  a  means  of  communication 
between  their  hosts  and  the  network. 

Integrating  the  network  protocols  into  an  existing  system  is  a 
more  difficult  problem.  Fundamentally,  there  are  two  basic  implemen¬ 
tation  options  -  inboard  (in  the  host  computer)  or  outboard  (in  a 
communications  processor  attached  to  the  host  computer). 

In  inboard  implementations,  the  network  protocols  can  be  written 
as  user-level  applications  or  as  operating  system  functions.  The 
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user-level  approach  has  the  advantage  of  simplicity;  the  protocols 
can  be  implemented  in  a  familiar,  veil-structured  programing 
environment.  However,  the  execution  environment  provided  by  operat¬ 
ing  systems  to  user  processes  is,  in  general,  not  veil  suited  to  the 
requirements  of  netvork  protocols;  therefore,  user- level  implementa¬ 
tions  may  result  in  poor  performance.  The  operating  system  approach, 
on  the  other  hand,  offers  a  less  favorable  programming  environment 
but  a  more  favorable  execution  environment.  Unfortunately,  some  of 
the  requirements  of  netvork  protocols  are  not  met  by  the  services  and 
capabilities  available  to  operating  system  processes.  Attempting  to 
meet  those  requirements  vbile  still  preserving  the  integrity  of  the 
operating  system  can  be  a  formidable  task. (4) 

The  other  alternative  is  an  outboard  implementation,  vhere  the 
netvork  protocols  are  moved  to  a  separate  front-end  processor.  This 
approach  provides  a  dedicated  environment  that  can  be  tailored  to  the 
specific  needs  of  the  netvork  protocols.  The  outboard  approach  is 
not  completely  free  of  problems,  however.  The  cost  of  a  separate  box 
may  be  incurred.  Also,  a  conmunication  mechanism  must  be  provided 
between  the  host  system  and  the  front-end  processor.  Although  it  is 
subject  to  the  same  processing  considerations  as  the  inboard  imple¬ 
mentation,  this  mechanism,  commonly  referred  to  as  a  host-to-front- 
end  protocol,  is  normally  easier  to  implement.  In  addition  to  the 
host-to-front-end  protocol  implementation  in  the  host,  the  applica¬ 
tion  protocols  must  also  be  implemented. 

A  standard  implementation  of  the  outboard  approach  that  will  be 
available  to  subscribers  is  the  DDN  Host  Front  End  Processor  (HFEP). 
The  HFEP  is  a  standard  configuration  of  the  DDN  Netvork  Access  Com¬ 
ponent  (NAC)  that  is  being  acquired  by  the  DDN  PMO  and  should  be 
available  to  subscribers  by  1986.  The  HFEP  implements  TCP/IP  and 
provides  a  standard  ARPANET  connection  to  the  netvork.  Conmunication 
between  the  subscriber  host  and  the  HFEP  is  supported  via  a  standard 


interface  connection  implementing  the  DDN  Host  Front-end  Protocol 
(HFP).  Development  of  the  host  portions  of  the  HFP,  together  vith 
network  services  such  as  TELNET,  native  synchronous  terminal  support, 
and  application  protocols,  are  the  responsibility  of  the  subscriber 
and  need  to  be  implemented  in  the  host. 

In  general,  the  selection  of  the  approach  (inboard  vs.  outboard) 
to  be  taken  for  a  particular  host  family  should  be  made  by  the  imple¬ 
mentor  of  the  interface  for  that  family.  The  selection  should  be 
based  on  subscriber  requirements,  host  hardware,  and  operating  system 
characteristics.  Subscriber  requirements,  such  as  system  perfor¬ 
mance,  may  dictate  that  an  inboard  approach  be  used.  The  character 
of  the  operating  system  may  be  the  overriding  consideration,  however. 
Older  types  of  operating  systems  tend  to  be  more  difficult  to  inter¬ 
face  to  networks,  and  an  outboard  approach  may  be  substantially 
easier.  On  the  other  hand,  a  contemporary  operating  system,  with  a 
process  structure  and  inherent  networking  capabilities,  may  accommo¬ 
date  an  inboard  implementation  fairly  easily. 

4.1.2  Limited  Service  Interfaces 

A  limited  service  interface  is  any  interface  to  the  DDN  that  is 
not  capable  of  supporting  the  full  functionality  offered  by  the  DDN 
protocol  architecture.  The  two  most  common  types  of  limited  service 
interfaces  of  interest  to  DDN  subscribers  are  those  interfaces  sup¬ 
ported  by  vendor-specific  protocol  architectures  and  terminal  emula¬ 
tion  interfaces. 

Under  certain  circumstances,  the  DDN  PMO  may  permit  subscribers 
to  connect  to  the  network  without  using  TCP/IF  as  the  network  proto¬ 
cols.  These  cases  are  limited  to  subscribers  without  immediate 
interoperability  requirements  who  are  waiting  for  a  full  service 
interface  development  to  be  completed.  This  form  of  limited  service 
interface  is  based  on  one  of  the  commercial  networking  strategies 
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that  uses  X.25.  Communication  among  these  subscribers  would  be  lim¬ 
ited  to  subscribers  with  similar  architectures,  i.e.,  homogenous  com¬ 
munication.  A  waiver  must  be  requested  for  this  mode  of  operation. 

The  simplest  form  of  host  connection,  which  avoids  implementa¬ 
tion  problems,  is  the  terminal  emulation  interface.  The  essence  of 
this  approach  is  to  attach  a  protocol  device  to  existing  terminal 
ports  on  the  host,  emulating  a  cluster  of  terminals.  This  approach 
facilitates  only  remote  terminal-to-host  communication;  i.e.,  local 
terminals  connected  to  the  host  cannot  access  the  network.  The  sub¬ 
scriber  will  not  be  able  to  take  advantage  of  other  network  services, 
since  the  higher  level  protocols  are  not  implemented  with  this 
approach.  The  advantage  of  the  terminal  emulation  interface  is  that 
no  modifications  to  the  host  system  software  are  required  to  connect 
a  host  to  the  network. 

Several  devices  are  available  that  support  the  terminal  emula¬ 
tion  approach.  One  is  a  standard  configuration  of  the  DDN  Network 
Access  Component  known  as  the  Terminal  Emulation  Processor  (TEP) .  A 
standard  TEP  will  support  sixteen  terminal  connections  to  the  host. 
Like  the  other  configurations  of  the  NAC,  the  TEP  implements  TCP/IP 
and  provides  a  standard  ARPANET  connection  to  the  network.  In  addi¬ 
tion,  the  TEP  implements  the  "server,"  or  host,  portion  of  the  TELNET 
protocol.  In  its  basic  configuration,  the  TEP  will  support  only 
asynchronous  connections  to  the  host.  With  the  addition  of  synchro¬ 
nous  interface  support,  the  TEP  may  be  used  to  provide  remote  syn¬ 
chronous  terminal-to-host  communication. 

Other  devices  that  may  be  used  to  support  terminal  emulation 
interfaces  include  those  connercial  host  interfaces  that  complement 
the  terminal  interfaces  described  in  Section  4.2.3. 


4.1.3  Combinations  of  Interfaces 

For  some  sets  of  user  requirements,  a  combination  of  interfaces 
may  be  most  appropriate.  For  example,  hosts  for  which  implementa¬ 
tions  of  all  the  DDN  protocols  except  Native  Mode  are  available  might 
use  a  combination  of  a  full  service  interface  and  a  terminal  emula¬ 
tion  interface  with  built-in  synchronous  terminal  support.  The  full 
service  interface  would  support  scroll  mode  terminal-to-host  communi¬ 
cation,  file  transfer,  and  electronic  mail  service.  The  terminal 
emulation  interface  would  support  native  mode  communication  between 
remote  synchronous  terminals  and  the  host. 

4.2  Terminals 

Subscribers  have  three  options  for  connecting  their  terminals  to 
the  DDN.  The  first  is  to  implement  a  pass-through  application  using 
the  "user"  portion  of  the  TELNET  protocol  in  a  host  system  that  is 
connected  to  the  network.  The  second  option  is  to  request  that  a 
direct  connection  to  the  network  be  provided  by  the  DDN  PMO.  The 
final  option  is  for  the  subscriber  to  obtain  Packet 
Assembly/Disassembly  facilities  (PADs)  or  other  similar  devices  that 
can  be  used  to  connect  terminals  to  the  network.  Since  this  method 
does  not  support  the  standard  DDN  protocols,  it  is  not  recommended  by 
the  DDN  PMO,  and  connections  of  this  type  will  be  handled  similarly 
to  limited  service  host  interfaces.  These  options  are  discussed  in 
the  following  subsections. 


4.2,1  Pass-through  Interfaces 


A  pass-through  interface  is  actually  part  of  a  subscriber  host 
interface  to  the  DDN.  The  pass-through  interface  is  implemented  as 
part  of  the  host  system's  standard  network  software  and  can  be  used 
by  local  terminals  to  access  the  DDN  through  the  host  or  its  associ¬ 
ated  front-end  processor.  The  local  host  must  implement  the  "user” 
portion  of  the  ARPANET  TELNET  protocol,  and  the  remote  host  must 
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implement  the  "server"  portion.  The  terminals  appear  to  the  remote 
host  as  though  they  were  locally  connected. 

4.2.2  Direct  Interfaces 

Direct  connection  of  terminals  to  the  network  is  supported  by 
two  devices  provided  by  the  Dm  PMO.  The  devices  are  the  Terminal 
Access  Controller  (TAC)  and  a  smaller  version  known  as  the  mini-TAC. 

The  Terminal  Access  Controller^)  i8  an  existing  operational 
component  of  the  ARPANET  and  will  continue  to  be  utilized  in  the  DDR. 
The  TAC  is  a  BBH  C/30  minicomputer  that  supports  up  to  63  asynchro¬ 
nous  terminal  access  ports.  Currently,  subscribers  can  connect  ter¬ 
minals  and  modems  that  conform  to  the  RS-232-C  specification  and  ter¬ 
minals  that  use  20  milliampere  current  loop  to  the  TAC.  The  TAC  sup¬ 
ports  communication  at  data  rates  from  75  to  9,600  bits  per  second. 
The  TAC  supports  the  standard  suite  of  ARPANET  protocols,  including 
TCP/IP,  a  standard  ARPANET  network  connection,  and  the  "user”  portion 
of  the  TELNET  protocol.  The  TAC  allows  a  terminal  user  to  coimuni- 
cate  with  any  host  on  the  network  without  going  through  an  interven¬ 
ing  local  host.  All  terminal-to-host  connections  are  multiplexed 
over  a  single  link  between  the  TAC  and  the  switching  node. 

Subscribers  have  indicated  that  a  low  cost  means  of  terminal 
access  is  required  in  locations  with  fever  terminals  thsn  are 
currently  supported  by  the  TAC.  In  these  situations,  a 
microprocessor-based  device  known  as  the  mini-TAC  will  be  provided  to 
support  up  to  16  terminal  connections  to  the  DDN.  The  mini-TAC  is  a 
standard  configuration  of  the  DDN  Network  Access  Component.  Like  the 
other  configurations  of  the  NAC,  the  mini-TAC  implements  TCP/IP  and 
provides  a  standard  ARPANET  connection  to  the  network.  In  addition, 
the  mini-TAC  implements  the  "user"  portion  of  the  TELNET  protocol. 
The  mini-TAC' will  meet  TEMPEST  and  HEMP  requirements.  Multiple  net¬ 
work  interface  ports  will  be  provided  to  allow  dual-homing. 


The  mini-TAC  vill  support  both  asynchronous  and  synchronous  ter¬ 
minals.  The  types  of  vendor-unique  synchronous  terminals  to  be  sup¬ 
ported  vill  be  based  on  subscriber  requirements  and  priorities.  The 
protocols  implemented  in  a  particular  mini-TAC  vill  be  those  neces¬ 
sary  to  support  the  terminals  that  are  attached  to  it.  Terminals 
connected  in  asynchronous  mode  vill  be  able  to  conmunicate  at  data 
rates  from  110  to  19,200  bits  per  second  and  in  synchronous  mode  from 
1,200  to  19,200  bits  per  second. 


4.2.3  Subscriber-supplied  Interfaces 

Subscribers  can  support  terminal  connections  to  the  DDN  through 
various  commercial  devices.  These  devices  fall  into  tvo  general 
categories:  PADs  and  X.25  interface  adapters. 

The  PAD  is  a  device  designed  to  provide  access  to  public  data 
netvorks.  PADs  perform  functions  similar  to  those  of  a  TAC  or  mini- 
TAC,  but  do  not  support  the  ARPANET  protocols.  A  standard  X.25  PAD, 
defined  by  the  CC1TT  recommendation  X.3,  conmunicate 6  vith  asynchro¬ 
nous  terminals  according  to  the  X.28  recommendation  and  vith  hosts 
according  to  the  X.29  recomnendation.  The  PAD  takes  inputs  from 
attached  scroll-mode  asynchronous  terminals,  forms  them  into  X.25 
packets,  and  transmits  the  packets  across  the  DDN  to  a  remote  ho6t. 

For  those  terminals  that  are  not  supported  by  a  PAD,  an  X.25 
terminal  interface  adapter  may  be  used  to  communicate  vith  an  X.25 
host.  Such  terminals  include  synchronous  and  page-mode  terminals. 
An  X.25  terminal  interface  adapter  functions  exactly  like  a  PAD, 
except  that  it  usually  supports  a  particular  class  of  synchronous 
terminal  protocols.  In  some  cases,  these  adapters  vill  also  support 
the  PAD  function.  In  general,  a  reverse  adapter  is  also  required  at 
any  host  to  vhich  communication  using  the  adapter  is  required. 


4.2.4  Combinations  of  Terminal  Interfaces 


For  some  subscribers,  combinations  of  interfaces  might  best  meet 
their  requirements.  For  example,  subscribers  with  a  combination  of 
asynchronous  terminals,  synchronous  terminals  for  which  there  is 
mini-TAC  support,  synchronous  terminals  for  which  there  is  an  X.25 
terminal  interface  adapter,  and  synchronous  devices  for  which  there 
is  no  DDN  support  might  use  a  combination  of  TACs,  mini-TACs,  X.25 
terminal  interface  adapters,  and  dedicated  lines  to  the  host  to  sup¬ 
port  the  full  requirement.  The  optimal  design  of  such  a  configura¬ 
tion  should  be  done  in  conjunction  with  the  DDN  PMO. 

4.3  Other  Networks 

The  DDN  Program  Plan  identifies  the  need  for  external  network 
gateways,  although  none  have  been  defined  or  provided  for  in  the 
plan.  The  gateways  will  provide  the  interface  between  local  networks 
and  the  DDN.  The  external  network  side  of  a  gateway  will  be  designed 
to  support  the  protocols  necessary  to  connect  to  the  local  network. 
The  DDN  side  of  a  gateway  will  be  designed  to  support  the  network 
access  protocols  necessary  to  connect  to  a  DDN  network  device.  To 
provide  Internet  service,  the  gateways  will  implement  IP.  The  design 
of  the  Internet  gateway  is  described  in  ARPANET  Request  for  Comments 
823. Communication  between  a  "stub"  gateway,  used  for  a  local  net¬ 
work  connection,  and  an  Internet  gateway  is  defined  by  the  Exterior 
Gateway  Protocol. (?)  Definition  of  gateways  for  the  DDN  will  proceed 
as  requirements  for  external  networks  are  identified. 


5.0  SUBSCRIBER  INTERFACE  ACQUISITION  STRATEGIES 

This  section  discusses  four  strategies  for  acquiring  full  ser¬ 
vice  host  interfaces  and  complementary  synchronous  terminal  inter¬ 
faces.  The  strategies  correspond  to  the  four  primary  sources  of 
these  interfaces: 

o  new  vendor  products, 

o  DCA-sponsored  developments, 

o  existing  ARPANET  implementations,  and 

o  subscriber-sponsored  developments. 

The  other  interfaces  that  were  described  in  the  previous  section 
are  either  existing  commercial  products  or  standard  configurations  of 
the  NAC,  and  as  such  have  well-defined  sources. 

5.1  New  Vendor  Products 

Motivated  by  the  increasing  visibility  of  the  DDN  Program,  some 
of  the  major  computer  vendors  are  initiating,  under  corporate  spon¬ 
sorship,  the  development  of  DDN  interfaces  for  selected  host  and  ter¬ 
minal  families  within  their  standard  product  lines.  As  these 
corporation-sponsored  developments  or  other  developments  (e.g.,  DCA- 
sponsored  or  subscriber-sponsored)  are  completed  and  incorporated 
into  vendors'  standard  product  lines,  they  will  become  the  preferred 
sources  of  DDN  interfaces.  Subscribers  will  be  able  to  acquire, 
install,  and  maintain  these  interfaces  in  the  same  way  as  other  ven¬ 
dor  products. 

5.2  DCA-sponsored  Developments 

From  the  beginning  of  the  DDN  Program,  DCA  has  been  committed  to 
ensuring  the  development  and  availability  of  host  and  synchronous 
terminal  interfaces  for  the  most  common  host  families  within  its  sub¬ 
scriber  community.  To  this  end,  DCA  is  planning  to  fund  the  develop- 
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ment  of  DDN  interfaces  for  those  major  host  families  whose  manufac¬ 
turers  are  unable  or  unwilling  to  internally  fund  the  necessary 
development  efforts.  Ideally ,  these  developments  would  evolve  into 
new  vendor  products,  with  all  the  inherent  advantages  thereof. 

Each  DCA-sponsored  development  effort  will  include  not  only  the 
development  of  host  and  synchronous  terminal  interfaces,  but  also  the 
installation  of  the  interfaces  at  a  DDN  subscriber  site.  The  test 
site  will  be  given  the  interfaces  free  of  charge,  although  computer 
time  will  be  needed  by  the  developers.  Other  subscribers  will  be 
able  to  purchase  or  lease  the  interfaces  directly  from  the  vendors. 


5.3  Exiati 


ANET  Implementations 


A  large  number  of  implementations  of  the  DDN  protocols  are 
currently  in  use  on  the  ARPANET.  However,  the  developers  of  these 
implementations  are  typically  universities  or  research  institutions 
that  have  neither  the  resources  nor  the  desire  to  convert  their 
implementations  to  commercial  quality,  to  tailor  their  implementa¬ 
tions  to  other  sites,  or  to  assume  responsibility  for  making  needed 
modifications  to  keep  abreast  of  changes  to  the  protocols  or  to  the 
subscriber's  operating  system.  Subscribers  may  be  able  to  make 
arrangements  to  transport  these  existing  implementations  to  their  own 
systems  if  they  are  willing  to  undertake  the  task  of  tailoring  and 
maintaining  them  or  if  they  can  find  a  developer  or  other  programming 
group  willing  to  undertake  these  tasks.  The  "Internet  Protocol 
Implementation  Guide"^®^  and  the  "ARPANET  Directory"^)  list  hosts 
with  existing  network  protocol  implementations. 

5.4  Subscriber-sponsored  Developments 

Subscribers  whose  requirements  cannot  be  met  by  any  of  the  above 
strategies  will  have  to  sponsor  their  own  interface  development 
efforts,  either  in-house  or  contracted-out.  DCA  will  coordinate 
these  efforts  to  ensure  that  unnecessary  duplications  are  avoided. 


There  are  several  valuable  resources  available  to  subscribers 
who  utilize  this  strategy.  The  foremost  is  the  DDN  HFEP,  which  pro¬ 
vides  implementations  of  TCP,  IP,  and  the  ARPANET  network  access  pro¬ 
tocols  that  are  accessible  through  the  DDN  standard  Host  Front-end 
Protocol*  Another  very  useful  resource  is  a  testing  facility,  housed 
at  the  Defense  Communications  Engineering  Center  (DCEC),  that  DCA 
will  provide  to  implementors.  Other  resources  include  Appendix  A 
(attached),  which  specifies  the  DDN  protocol  suite,  and  the  "Internet 
Protocol  Implementation  Guide,"^^  which  offers  general  guidelines  to 
implementors  of  DDN  protocols. 


6 .0  SUMMARY 


This  section  summarizes  in  table  form  the  information  presented 
in  this  Guide.  Table  1  summarizes  the  protocols  and  interfaces  that 
are  needed  for  particular  network  services.  For  example,  the  table 
shows  that  subscribers  who  require  network-based  file  transfer  ser¬ 
vices  must  implement  the  standard  FTP  and  must  implement  a  full  ser¬ 
vice  host  interface.  Table  2  summarizes  the  guidelines  for  choosing 
between  competing  interface  methods,  such  as  whether  to  connect  a 
terminal  through  a  mini-TAC  or  through  a  host.  Table  3  lists  the 
advantages  and  disadvantages  of  the  general  strategies  that  are 
available  for  acquiring  full  service  host  interfaces. 


Table  1: 

Summary  of  Subscriber  Interfaces 


SERVICE 

PROTOCOL* 

INTERFACES 

asynchronous 

terminal 

to 

host 

communication 

TELNET 

Terminal:  TAC,  standard  mini-TAC  (direct) 

full  service  host  interface  (pass 
through) 

Host:  standard  TEP,  full  service  host 

interface 

synchronous 

terminal 

to 

native  host 
communication 

Native  Mode 

Terminal:  terminal-specific  mini-TAC  (direct) 
full  service  host  interface  (pass 
through) 

Host:  terminal-specific  TEP,  full  service 

host  interface 

synchronous 

terminal 

to 

nonnative  host 
communication 

TELNET 

Terminal:  terminal-specific  mini-TAC  (direct) 
full  service  host  interface  (pass 
through) 

Host:  full  service  host  interface 

file 

transfer 

FTP 

full  service  host  interface 

electronic 

mall 

SMTP 

full  service  host  interface 

reliable 
internetwork 
process-to-process 
communicat ion 

TCP 

full  service  host  interface 

internetwork 

host-to-host 

communication 

(potentially 

unreliable) 

IP 

full  service  host  interface 

support  of 
vendor-provided 
services  designed 
to  run  on  Public 

Data  Networks 

X.  25 

X.25-based  full  service  host  interface 

This  column  references  only  the  highest  level  protocol  associated  with  each  service. 


Table  2: 

Summary  of  Interfacing  Strategies 


Interface  Strategy 


Conditions  for  Employment 


full  service  host  interface 
(inboard  implementation) 

full  interoperability  at  the 
application  level  is  required 

full  service  host  interface 
(outboard  implementation) 

same  as  inboard,  except  that 
operating  environment  dictates 
outboard  solution 

limited  service  host  interface 
(vendor-specific) 

interim  solution  only,  where 
interoperability  is  not  required 
and  vendor-specific  protocols  are 
available 

limited  service  host  interface 
(terminal  emulation) 

terminal-to-host  communication  is 
required  immediately,  prior  to 
development  of  full  service  interface; 
or,  cost  of  full  service  interface 
is  prohibitive 

terminal  interface 
(pass  through) 

users  with  terminals  directly  connected 
to  subscriber  host  also  require 
communication  with  other  hosts 

terminal  interface 
(direct) 

user  with  stand-alone  terminal 
requires  communication  with 
remote  hosts 

terminal  interface 
(subscriber-supplied) 

same  as  direct,  except  that  terminal 
and  host  characteristics  dictate 
subscriber-specific  solution 

external  network  interface 

communication  between  terminals  or 
hosts  of  a  subscriber  network,  such 
as  a  local  area  network,  and  remote 
hosts  is  required 

Table  3: 

Summary  of  Interface  Acquisition  Strategies 


Strategy 
(Source  of 
Interface) 

Advantages 

Disadvantages 

new 

vendor 

products 

vendor  funds  development  and 
establishes  procedures  for 
acquisition.  Installation 
and  maintenance 

not  currently  available 

DCA-sponsored 

developments 

DCA  funds  development  and 
helps  to  establish  procedures 
for  acquistion,  installation, 
and  maintenance 

not  currently  available 

existing 

ARPANET 

Implementations 

currently  available 

subscriber  must  establish 
procedures  for  installation 
(i.e.,  site  tailoring)  and 
maintenance 

subscriber- 

sponsored 

developments 

interface  can  be  customized 
to  meet  subscriber's  unique 
requirements ;  subscriber 
establishes  schedule  of 
availability 

subscriber  must  fund 
development  and  establish 
procedures  for  acquisition, 
installation,  and  maintenance 
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1.1  Purpose 

The  purpose  of  this  specification  is  to  define  the  standard  data  com¬ 
munication  interfaces  and  protocols  to  be  used  by  subscribers  of  the 
Defense  Data  Network  (DDN). 

1 .2  Scope 

This  specification  defines  the  interfacing  requirements  and  communi¬ 
cation  protocols  for  the  connection  of  host  and  terminal  subscribers 
to  the  DDN.  The  standard  methods  of  connection  to  the  network  may  be 
supported  in  part  by  the  DDN  Network  Access  Component  (NAC) ,  which 
may  be  configured  as  a  mini-Terminal  Access  Controller  (mini-TAC)t  a 
Host  Front  End  Processor  (HFEP),  or  a  Terminal  Qnulation  Processor 
(TEP) .  Host  subscribers  may  connect  directly  to  the  DDN  or  may  util¬ 
ize  the  HFEP  or  TEP  configurations  of  the  NAC.  Direct  connection  on 
the  unclassified  segment  of  the  network  will  be  to  a  C/30  network 
node.  Direct  connection  on  the  classified  segment  will  be  to  an 
Internet  Private  Line  Interface  (IFLI).  Terminal  subscribers  may 
connect  to  the  DDN  via  a  Terminal  Access  Controller  (TAC),  the  mini- 
TAC  configuration  of  the  NAC,  or  through  a  TELNET  or  "native  mode" 
implementation  in  a  host  system  connected  to  the  DDN. 

For  the  purposes  of  this  specification,  the  term  "host”  will  include 
a  host  computer  system  and  its  native  conmuni cat ions  front  end. 

This  specification  does  not  include  the  requirements  for  user,  pro¬ 
gram,  or  file  system  interfaces  to  the  various  services  which  the 
protocols  support.  Any  such  required  interfaces  and  their  func¬ 
tionality  should  be  specified  by  the  subscriber.  Examples  of  such 
interfaces  are  interactive  user  interfaces  to  a  terminal- to- host, 
file  transfer,  or  electronic  mail  service;  file  system  interfaces  for 
file  transfer  and  electronic  mail;  and  program  interfaces  (e.g., 


subroutine  calls)  for  file  transfer,  reliable  transport  (Transmission 
Control  Protocol),  datagram  transport  (Internet  Protocol),  or  network 
access  services. 


1 .3  Objective 

The  objective  of  this  specification  is  to  establish  standard  inter¬ 
faces  and  protocols  for  the  DDN  such  that  data  communication  can  take 
place  among  independently  manufactured  equipments  with  minimum  effort 
on  the  part  of  DDN  subscribers  and  implementors  of  the  interfaces  and 
protocols. 

1 .4  Application 

This  specification  shall  apply  to  the  connection  of  host  and  terminal 
subscribers  to  the  DDN,  as  well  as  to  the  development  of  all  new 
standard  interfaces  and  interface' devices  supporting  subscriber  con¬ 
nection  to  the  DDN.  Contracts  invoking  this  specification  should 
specifically  identify  the  paragraphs  or  portions  thereof  applicable 
to  the  program  being  procured.  The  contractor  shall  be  responsible 
for  determining  the  extent  to  which  the  requirements  contained  herein 
are  applicable  to  subcontractors,  vendors,  and  suppliers  and  for  the 
application  of  the  requirements  to  subcontractors,  vendors,  and  sup¬ 
pliers. 

1 .5  Usage  note 

Two  types  of  information  are  included  in  this  specification:  text 
intended  to  be  included  in  a  RFP  or  other  interface  requirement  docu¬ 
ment  and  explanatory  information  for  subscribers.  The  latter  infor¬ 
mation  is  set  off  by  square  brackets. 


2.  APPLICABLE  DOCUMENTS 


2.1  Go-gernmpnt  standards 

Unless  otherwise  specified,  the  following  standards  of  the  issue 
listed  in  that  issue  of  the  Department  of  Defense  Index  of  Specifica¬ 
tions  and  Standards  (DoDISS)  specified  in  the  solicitation  form  a 
part  of  this  specification  to  the  extent  specified  herein. 

FEDERAL  STANDARDS 

FED-STD-1001 ,  Telecommunications:  Synchronous  High  Speed 
Data  Signaling  Rates  Between  Data  Terminal  Equipment  and 
Data  Communication  Equipment. 

FED-STD-1010,  Telecommunications:  Bit  Sequencing  of  the 
American  National  Standard  Code  for  Information  Interchange 
in  Serial-by-bit  Data  Transmission.  (Adoption  of  American 
National  Standards  Institute  standard  X3. 15-1979) 

FED-STD-1011 ,  Telecommunications:  Character  Structure  and 
Character  Parity  Sense  for  Serial-by-bit  Data  Communication 
in  the  American  National  Standard  Code  for  Information 
Interchange.  (Adoption  of  American  National  Standards 
Institute  standard  X3. 16-1 97 9) 

FED-STD-1013 ,  Telecommunications:  Synchronous  Signaling 
Rates  Between  Data  Terminal  Equipment  and  Data  Circuit- 
Terminating  Equipment  Utilizing  4kHz  Circuits.  (Adoption  of 
American  National  Standards  Institute  standard  X3. 1-1979) 

FED-STD-1031 ,  Telecommunications:  General  Purpose  37- 
Position  and  9-Position  Interface  Between  Data  Terminal 
Equipment  and  Data  Circuit  Terminating  Equipment.  (Adoption 
of  Electronic  Industries  Association  standard  RS-449) 

FED-STD-1037 ,  Glossary  of  Telecommunication  Terms. 

INT-FED-STD-1041 ,  Telecommunications:  Interface  between  data 
terminal  equipment  and  data  circuit- terminating  equipment 
for  operation  with  packet-switching  data  communication  net¬ 
works.  (Adoption  of  International  Telegraph  and  Telephone 
Consultative  Committee  Recommendation  X.25) 
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(Application  for  copies  should  be  addressed  to  the  Superintendent  of 

Documents,  Government  Printing  Office  (GPO),  Washington,  DC  20402  or 

* 

the  National  Technical  Information  Service  (NTIS) ,  5285  Port  Royal 

Road,  Springfield,  VA  22161.) 

FEDERAL  INFORMATION  PROCESSING  STANDARDS 

FIPS  POB  1-1,  Code  for  Information  Interchange.  (Adoption 
of  American  National  Standards  Institute  standard  X3 .4-1977) 

(Application  for  copies  should  be  addressed  to  the  National  Technical 
Information  Service,  5285  Port  Royal  Road,  Springfield,  VA  22161.) 

MILITARY  STANDARDS 

MIL-STD-188C,  Military  Communication  System  Technical  Stan¬ 
dards  . 

MIL-STD-1 88-100,  Common  Long  Haul  and  Tactical  Communication 
System  Technical  Standards. 

MIL-STD  1777,  Internet  Protocol  Standard. 

MIL-STD  1778,  Transmission  Control  Protocol  Standard. 

(Application  for  copies  should  be  addressed  to  the  Naval  Publications 
and  Forms  Center  (NPFC),  5801  Tabor  Avenue,  Philadelphia,  PA  19120.) 

2.2  Other  publications 

The  following  documents  form  a  part  of  this  specification  to  the 
extent  specified  herein.  The  issues  of  the  documents  which  are  indi¬ 
cated  as  DoD  adopted  shall  be  the  issue  listed  in  the  current  DoDISS 
and  the  supplement  thereto,  if  applicable. 

AMERICAN  NATIONAL  STANDARDS  INSTITUTE  (ANSI) 

ANSI  X3. 1-1979,  Synchronous  Signaling  Rates  for  Data 
Transmission. 

ANSI  X3 .4-1 977,  American  National  Standard  Code  for  Informa¬ 
tion  Interchange. 
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ANSI  X3. 15-1 979,  Bit  Sequencing  of  the  American  National 
Standard  Code  for  Information  Interchange  in  Serial-by-bit 
Data  Transmission. 

ANSI  X3. 16-1979,  Character  Structure  and  Character  Parity 
Sense  for  Serial-by-bit  Data  Conmunication  in  the  American 
National  Standard  Code  for  Information  Interchange. 

(Application  for  copies  should  be  addressed  to  the  American  National 
Standards  Institute,  1430  Broadway,  Nev  York,  NY  10018.) 

ELECTRONIC  INDUSTRIES  ASSOCIATION  (EIA) 

EIA  RS-232-C,  Interface  between  data  terminal  equipment  and 
data  communication  equipment  employing  serial  binary  data 
interchange. 

EIA  RS-449,  General  purpose  37-position  and  9-position 
interface  for  data  tezminal  equipment  and  data  circuit¬ 
terminating  equipment  employing  serial  binary  data  inter¬ 
change. 

(Application  for  copies  should  be  addressed  to  the  Electronic  Indus¬ 
tries  Association,  Standards  Sales,  2001  Eye  Street,  NW,  Washington, 
DC  20006.) 

INTERNATIONAL  TELEGRAPH  AND  TELEPHONE  CONSULTATIVE  COMMITTEE  (CCITT) 

Recommendation  X.25:  Interface  between  data  terminal  equip¬ 
ment  (DTE)  and  data  circuit-terminating  equipment  (DCE)  for 
terminals  operating  in  the  packet  mode  on  public  data  net¬ 
works  . 

(Application  for  copies  should  be  addressed  to  the  National  Technical 
Information  Service  (NTIS),  5285  Port  Royal  Road,  Springfield,  VA 
22161.) 

NETWORK  INFORMATION  CENTER  (NIC) 

RFC  765,  File  Transfer  Protocol,  June  1980. 

RFC  792,  Internet  Control  Message  Protocol,  September  1981. 


RFC  795,  Service  Mappings,  September  1981. 

RFC  796,  Address  Mappings,  September  1981. 

RFC  820,  Assigned  Numbers,  January  1983. 

RFC  821,  Simple  Mail  Transfer  Protocol,  August  1982. 

RFC  822,  Standard  for  the  Format  of  ARPA  Internet  Text  Mes¬ 
sages,  August  1982. 

RFC  854,  TELNET  Protocol  Specification,  May  1983. 

RFC  856,  TELNET  Binary  Transmission  Option,  May  1983. 

RFC  857,  TELNET  Echo  Option,  May  1983. 

RFC  858,  TELNET  Suppress  Go  Ahead  Option,  May  1983. 

RFC  859,  TELNET  Status  Option,  May  1983. 

RFC  860,  TELNET  Timing  Mark  Option,  May  1983. 

RFC  861,  TELNET  Extended  Options  List  Option,  May  1983. 

(Application  for  copies  should  be  addressed  to  the  ARPANET  Network 
Information  Center,  SRI  International,  Menlo  Park,  CA  94025.) 

OTHER  DOCUMENTS 

Day,  J.D.,  et  al..  "WWMCCS  Host  to  Front  End  Protocols: 
Specifications  Version  1.0,"  DTI  Document  78012. C-INFE. 14, 
Digital  Technology  Incorporated,  November  1979.  (AD 
A100515/6) 

INTERFACE  MESSAGE  PROCESSOR  -  Specifications  for  the  Inter¬ 
connection  of  a  Host  and  an  IMP,  BBN  Report  No.  1822,  Bolt 
Beranek  and  Newman  Inc.,  December  1981  Revision.  (AD 
A00  27  51) 

(Application  for  copies  should  be  addressed  to  the  National  Technical 
Information  Service  (NTIS) ,  5285  Port  Royal  Road,  Springfield,  VA 

22161.) 
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Defense  Data  Network  Service  Access  Protocols,  the  MITRE 
Corporation. 

IPLI  Interface  Specification,  IPLI-83-6(U) ,  BBN  Report  No. 
5278,  Bolt  Beranek  and  Newman  Inc.,  March  1983. 

IPLI  Site  Preparation  and  Installation  Guide,  IPLI-82-27(0) , 
BBN  Report  No.  5224,  Bolt  Beranek  and  Newman  Inc.,  March 
1983. 

TAC  Users"  Guide,  BBN  Report  No.  4780,  Bolt  Beranek  and  New¬ 
man  Inc.,  October  1982. 

(Application  for  copies  should  be  addressed  to  the  procuring  activity 
or  as  directed  by  the  contracting  officer.) 

2.3  Order  of  precedence 

In  the  event  of  a  conflict  between  the  text  of  this  specification  and 
the  references  cited  herein,  the  text  of  this  specification  shall 
take  precedence. 


3 .  REQUIREMENTS 


3.1  Subscriber  interfaces  to  DON  components 

3.1.1  Host  connection  to  a  C/30 

3. 1.1.1  General 

3.1 .1.1.1  Each  subscriber  host  shall  implement  the  data  terminal 
equipment  (DTE)  side  of  a  DTE/data  circuit-terminating  equipment 
(DCE)  interface  with  the  following  physical,  data  link,  and  network 
level  characteristics. 

3. 1.1. 2  Physical  interface 

3. 1.1. 2.1  The  physical  interface  shall  conform  to  the  requirements  of 
FED-STD-1031 .  The  provisions  of  Section  6.C  shall  apply.  [This  is 
the  preferred  interface.  Existing  equipment  with  RS-232-C,  MIL-STD- 
188C,  and  MIL-STD-188-114  interfaces  can  also  be  accomodated.  For 
such  equipment,  this  paragraph  should  be  replaced  with  an  appropriate 
substitute,  and  the  DDN  Program  Management  Office  (PMO)  should  be 
informed  of  the  substitution  so  that  appropriate  interfaces  can  be 
supplied  on  the  C/30.] 

3.1 .1.2.2  The  Type  SR  data  transmission  configuration,  as  specified 
in  Section  5.2  of  EIA  RS-449,  shall  apply.  All  interchange  circuits 
with  the  exception  of  those  designated  0  (optional)  in  Table  7  of  the 
document  entitled  "IPLI  Site  Preparation  and  Installation  Guide,"  BBN 
Report  No.  5224,  shall  be  implemented.  The  37-position  interface 
connector  specified  in  Section  3.3  of  EIA  RS-449  shall  be  used.  The 
optional  9-position  interface  connector  is  not  required. 

3. 1.1. 2. 3  The  interface  shall  be  capable  of  transmitting  and  receiv¬ 
ing  binary  data  at  one  or  more  of  the  following  discrete  data 
transmission  rates:  4800,  9600,  19200,  50000  and  56000  bits  per 
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second.  [Subscribers  should  select  the  actual  rates  based  on  opera¬ 
tional  requirements,  coordinated  vith  the  DDN  PMO.] 


3. 1.1. 3  Netvork  and  data  link  protocols 

3. 1.1. 3.1  General 

3.1 .1.3. 1.1  The  interface  shall  support  either  an  implementation  of 
the  ARPANET  host  access  protocols  or  an  implementation  of  the  X.25 
protocol.  [Subscribers  should  select  the  interface  based  on  opera¬ 
tional  requirements,  coordinated  vith  the  DDN  PMO.  Subscribers  may 
not  implement  an  X.25  interface  until  an  approved  DDN  X.25  specifica¬ 
tion  has  been  issued.] 

3.1. 1.3.2  ARPANET 

3. 1.1 .3. 2.1  ARPANET  implementations  shall  support  the  ARPANET  High- 
level  Data  Link  Control  (HDLC)  Distant  Host  (HDH)  interface,  as 
specified  in  Appendix  J  of  the  document  entitled  "INTERFACE  MESSAGE 
PROCESSOR  -  Specifications  for  the  Interconnection  of  a  Host  and  an 
IMP,"  BBN  Report  No.  1822. 

3.1.1 .3.2.2  Assignment  of  link  numbers  in  the  "Message- ID"  field  of 
the  ARPANET  Host-IMP  interface  leader  shall  be  in  accordance  vith 
Request  for  Comments  (RFC)  820,  or  its  successor.  Specific  number 
assignments,  vhen  required,  shall  be  requested  from  the  DM  Program 
Management  Office  (PMO)  Data  Base  and  Configuration  Management 
Branch,  Code  B628. 

3. 1.1. 3. 2. 3  Unless  otherwise  specified,  HDH  shall  be  implemented  to 
operate  in  the  packet  mode,  as  specified  in  Appendix  J  of  BBN  Report 
No.  1822.  Alternatively,  HDH  shall  be  implemented  to  operate  in  mes¬ 
sage  mode.  [Subscribers  should  select  the  mode  based  on  operational 
requirements,  coordinated  vith  the  DDN  PMO.] 


3.1.1 .3.2.4  The  required  HDLC  mode  of  operation  is  LAP  B,  as  speci¬ 
fied  in  Section  4.2  of  INT-FED-STD-1041 . 

3. 1.1. 3 .2. 5  Two  vay  simultaneous  operation  shall  be  supported. 

3.1.1 .3.2.6  The  HDLC  system  parameters  shall  be  set  as  specified  in 
Appendix  J  of  BBN  Report  No.  1822.  All  system  parameters  shall  be 
settable. 

3.1. 1.3.3  X.25 

3.1.1 .3.3.1  X.25  implementations  shall  conform  to  the  requirements  of 
the  DDN  X.25  Specification,  to  be  issued  in  a  revision  to  this 
specification. 

3.1.2  Host  connection  to  an  IPL1 

3. 1.2.1  General 

3.1 .2.1.1  Each  subscriber  host  shall  implement  the  DTE  side  of  a 
DTE/DCE  interface  with  the  following  physical,  data  link,  and  network 
level  characteristics. 

3. 1.2. 2  Physical  interface 

3.1 .2.2.1  The  physical  interface  shall  conform  to  the  requirements  of 
Section  3.2.2  of  BBN  Report  No.  5224.  The  37-position  interface  con¬ 
nector  specified  in  Section  3.3  of  EIA  RS-449  shall  be  used.  The 
optional  9-position  interface  connector  is  not  required. 

3. 1.2. 2. 2  The  interface  shall  be  capable  of  transmitting  and  receiv¬ 

ing  binary  data  at  one  or  more  of  the  following  discrete  data 
transmission  rates:  4800,  9600,  19200,  50000  and  56000  bits  per 

second.  [Subscribers  should  select  the  actual  rates  based  on  opera¬ 
tional  requirements,  coordinated  with  the  DDN  PM0.1 


3. 1.2. 3  Network  and  data  link  protocols 


3.1 .2.3.1  The  interface  shall  implement  the  Host  to  IPLI  Protocol 
(HIP),  as  specified  in  Section  3.2  of  the  document  entitled  "IPLI 
Interface  Specification,"  BBN  Report  No.  5278.  The  HDH  option  shall 
be  implemented. 

3. 1.2.3 .2  Assignment  of  link  numbers  in  the  "Message- ID"  field  of  the 
HIP  interface  leader  shall  be  in  accordance  with  RFC  820,  or  its  suc¬ 
cessor.  Specific  number  assignments,  when  required,  shall  be 
requested  from  the  DDN  PMO  Data  Base  and  Configuration  Management 
Branch,  Code  B628. 

3. 1.2. 3. 3  Unless  otherwise  specified,  HDH  shall  be  implemented  to 
operate  in  the  packet  mode,  as  specified  in  Appendix  J  of  BBN  Report 
No.  1822.  Alternatively,  HDH  shall  be  implemented  to  operate  in  mes¬ 
sage  mode.  [Subscribers  should  select  the  mode  of  operation  based  on 
operational  requirements,  coordinated  with  the  DDN  PMO.] 

3.1 .2.3.4  The  required  HDLC  mode  of  operation  is  LAP  B,  as  specified 
in  Section  4.2  of  INT-FED-STD-1041 . 

3 .1.2.3 .5  Two  way  simultaneous  operation  shall  be  supported. 

3 .1.2.3 .6  The  HDLC  system  parameters  shall  be  set  as  specified  in 
Appendix  J  of  BBN  Report  No.  1822.  The  maximum  information  field 
shall  be  modified  in  accordance  with  Section  3.2-7  of  BBN  Report  No. 
5278.  All  system  parameters  shall  be  settable. 

3.1.3  Host  connection  to  a  HFEP 
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3.1 .3.2.1  The  physical  interface  shall  conform  to  the  requirements  of 
FED-STD-1031.  The  provisions  of  Section  6.C  shall  apply. 

3.1 .3.2.2  The  Type  SR  data  transmission  configuration,  as  specified 
in  Section  5.2  of  EIA  RS-449,  shall  apply.  All  interchange  circuits 
with  the  exception  of  those  designated  0  (optional)  in  Table  7  of  BBN 
Report  No.  5224  shall  be  implemented.  The  37-position  interface  con¬ 
nector  specified  in  Section  3.3  of  EIA  RS-449  shall  be  used.  The 
optional  9-position  interface  connector  is  not  required. 

3.1 .3.2.3  The  interface  shall  be  capable  of  transmitting  and  receiv¬ 
ing  binary  data  at  one  or  more  of  the  following  discrete  data 
transmission  rates:  4800,  9600,  19200,  50000  and  56000  bits  per 
second.  [Subscribers  should  select  the  actual  rates  based  on  opera¬ 
tional  requirements,  coordinated  with  the  DDN  PM0. ] 

3.1 .3.3  Network  and  data  link  protocols 


3. 1.3 .3.1  Host-to— HFEP  communication  shall  conform  to  the  require¬ 
ments  of  the  DDN  Host  Front-end  Protocol  (HFP),  as  specified  in  the 
document  entitled  "WWMCCS  Host  to  Front  End  Protocols:  Specifications 
Version  1.0." 

3.1 .3.3.2  Service  access  protocols  for  the  DDN  HFP  shall  conform  to 
the  requirements  of  the  documents  entitled  "Defense  Data  Network  Ser¬ 
vice  Access  Protocols." 

3. 1.3 .3 .3  The  HFP  Link  Protocol  shall  conform  to  the  requirements  of 
Section  4.2  of  INT-FED-STD-1041 . 

3 .1.3 .3 .4  Two  way  simultaneous  operation  shall  be  supported. 

3.1 .3.3.5  The  HDLC  system  parameters  shall  be  set  as  specified  in 
Appendix  J  of  BBN  Report  No.  1822.  All  system  parameters  shall  be 
settable. 


3. 1.4.1  General 

3. 1.4. 1.1  Subscriber  hosts  shall  interface  to  the  TEP  via  their  ter- 
tninal  ports  in  accordance  vith  the  following  physical  and  functional 
characteristics . 

3. 1.4. 2  Physical  interface 

3.1 .4.2-1  The  physical  interface  shall  conform  to  the  requirements  of 
FED-STD-1031 .  For  all  interfaces  conforming  to  EIA  RS-232-C,  the 
provisions  of  Section  6.4  shall  apply.  For  all  interfaces  conforming 
to  MIL-STD-188C  or  MIL-STD-1 88-100,  the  provisions  of  Section  6.B 
shall  apply.  For  all  other  interfaces,  the  provisions  of  Section  6.C 
shall  apply. 

3.1 .4.2.2  The  Type  SR  data  transmission  configuration,  as  specified 
in  Section  5.2  of  EIA  RS-449,  shall  apply.  All  interchange  circuits 
with  the  exception  of  those  designated  0  (optional)  in  Table  7  of  BBN 
Report  Ho.  5224  shall  be  implemented.  The  37-position  interface  con¬ 
nector  specified  in  Section  3.3  of  EIA  RS-449  shall  be  used.  The 
optional  9-position  interface  connector  is  not  required. 

3.1 .4.2.3  The  interface  shall  be  capable  of  transmitting  and  receiv¬ 
ing  binary  data  at  one  or  more  of  the  following  discrete  data 
transmission  rates:  110,  134.5,  150,  300,  600,  1200,  1800,  2400, 
4800,  9400,  and  19200  bits  per  second.  The  same  data  rates  shall  be 
used  for  both  transmit  and  receive. 

3. 1.4. 3  Functional  characteristics 
3.1. 4.3.1  Asynchronous 


3. 1.4. 3. 1.1  The  standard  transmission  code  set  shall  be  the  American 
Rational  Standard  Code  for  Information  Interchange  (ASCII),  as  speci- 


fied  in  FIPS  PUB  1-1.  [EBCDIC  and  BCD  code  sets  will  also  be  sup¬ 
ported.] 

3. 1.4.3 .1.2  Serial-by-bit  data  transmissions  shall  conform  to  FED- 
STD-1010  for  code  sequence  and  FED-STD-1011  for  character  structure 
and  parity  sense.  [Character  lengths  of  five  thru  nine  bits  per 
character  will  be  supported.  One.  one  and  one-half,  and  two  stop 
bits  will  be  supported.  Odd,  even,  mark,  and  space  parity  options 
will  be  supported.] 

3 .1.4.3 .1.3  Two  way  simultaneous  and  two  way  alternate  operation 
shall  be  supported. 

3.1 .4.3 .1.4  The  use  of  alternate  transmission  code  sets,  code 
sequences,  character  structures,  and  parity  sense  definitions  shall 
not  be  precluded.  [Link  level  terminal  flow  control  procedures,  such 
as  XOH/XOFF,  need  to  be  supported  in  the  host.] 

3.1. 4.3. 2  Synchronous 

3. 1.4.3 .2.1  To  Be  Determined  (TBD)  [Synchronous  support  will  be  added 
to  the  TKP  based  on  subscriber  requirements.] 


3.1.5  Termi 


connection  to 


» 


3. 1*6. 2  Physical  interface 


% 


3. 1.6. 2.1  The  physical  interface  shall  conform  to  the  requirements  of 
FED-STD-1031.  For  all  terminals  conforming  to  EIA  RS-232-C,  the  pro¬ 
visions  of  Section  6.A  shall  apply.  For  all  terminals  conforming  to 
MIL-STD-188C  or  MIL-STD-1 88-100,  the  provisions  of  Section  6.B  shall 
apply.  For  all  other  terminals,  the  provisions  of  Section  6.C  shall 
apply. 

3.1 .6.2.2  The  Type  SR  data  transmission  configuration,  as  specified 
in  Section  5.2  of  EIA  RS-449,  shall  apply.  All  interchange  circuits 
with  the  exception  of  those  designated  0  (optional)  in  Table  7  of  BBN 
Report  No.  5224  shall  be  implemented.  The  37-position  interface  con¬ 
nector  specified  in  Section  3.3  of  EIA  RS-449  shall  be  used.  The 
optional  9-position  interface  connector  is  not  required, 

3. 1.6. 2.3  Standard  signaling  rates  up  to  9600  bits  per  second  shall 
conform  to  FED-STD-1013.  Signaling  rates  above  9600  bitB  per  second 
shall  conform  to  FED-STD-1001 .  The  interface  shall  be  capable  of 
transmitting  and  receiving  binary  data  at  one  or  more  of  the  follow¬ 
ing  discrete  data  transmission  rates:  110,  134.5,  150,  300,  600, 
1200,  1800,  2400,  4800,  9600,  and  19200  bits  per  second.  The  same 
data  rates  shall  be  used  for  both  transmit  and  receive. 

3.1 .6.3  Functional  characteristics 

3. 1.6. 3.1  Asynchronous 

3. 1.6 .3 .1.1  The  standard  transmission  code  set  shall  be  the  American 
National  Standard  Code  for  Information  Interchange,  as  specified  in 
FIPS  PUB  1-1.  [EBCDIC  and  BCD  code  sets  will  also  be  supported.] 

3.1 .6.3. 1.2  Serial-by-bit  data  transmissions  shall  conform  to  FED- 
STD-1010  for  code  sequence  and  FED-STD-1011  for  character  structure 
and  parity  sense.  [Character  lengths  of  five  thru  nine  bits  per 
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character  will  be  supported.  One,  one  and  one-half,  and  two  stop 
bits  will  be  supported.  Odd,  even,  mark,  and  space  parity  options 
will  be  supported.] 

3. 1.6 .3. 1.3  Two  way  simultaneous  and  two  way  alternate  operation 
shall  be  supported. 

3. 1.6 .3. 1.4  The  use  of  alternate  transmission  code  sets,  code 
sequences,  character  structures,  and  parity  sense  definitions  shall 
not  be  precluded. 

3. 1.6 .3 .2  Synchronous 

3. 1.6.3. 2.1  TBD  [Synchronous  support  will  be  added  to  the  mini-TAC 
based  on  subscriber  requirements.] 

3.2  Host  level  protocols 

3.2.1  Internet  service 


3.2.1 .1  Internet  service  shall  conform  to  the  requirements  of  the  DoD 
standard  Internet  Protocol  (IP),  as  specified  in  MIL-STD-1777. 

3. 2. 1.2  All  IP  options,  as  specified  in  Section  6.2.14  of  MIL-STD- 
1777,  shall  be  implemented. 

3. 2. 1.3  The  maximum  IP  datagram  shall  be  4608  bits.  All  IP  system 
parameters  shall  be  settable.  [4608  bits  allows  a  data  block  of  512 
octets  plus  64  header  octets  to  fit  in  a  datagram.] 

3.2.1 .4  Assignment  of  network  numbers,  internet  version  numbers,  and 
internet  protocol  numbers  shall  be  in  accordance  with  RFC  820,  or  its 
successor.  Specific  number  assignments,  when  required,  shall  be 
requested  from  the  DDN  PMO  Data  Base  and  Configuration  Management 
Branch,  Code  B628. 

3.2.1 .5  Mapping  of  the  IP  "Type  of  Service”  field  to  the  actual  ser¬ 
vice  provided  shall  be  in  accordance  with  the  document  entitled  "Ser- 


▼ice  Mappings,"  RFC  795,  or  its  successor.  Specific  service  mapping 
for  the  DDH  shall  be  requested  from  the  DDN  PMO  Data  Base  and  Confi¬ 
guration  Management  Branch,  Code  B628. 

3. 2. 1.6  Mapping  of  the  IF  address  fields  shall  be  in  accordance  vith 
the  document  entitled  "Address  Mappings,"  RFC  796,  or  its  successor. 
Specific  address  mapping  for  the  DDR  shall  be  requested  from  the  DDN 
PMO  Data  Base  and  Configuration  Management  Branch,  Code  B628. 

3. 2. 1.7  Internet  control  messages  shall  conform  to  the  requirements 
of  the  Internet  Control  Message  Protocol  (ICMP),  as  specified  in  the 
document  entitled  "Internet  Control  Message  Protocol,"  RFC  792. 

3. 2. 1.8  Implementations  shall  be  capable  of  receiving  all  ICMP  mes¬ 
sage  types.  As  a  minimum,  implementations  shall  be  capable  of  send¬ 
ing  the  following  ICMP  message  types: 

a .  Echo  Reply 

b.  Source  Quench 

c.  Destination  Unreachable 

d.  Time  Exceeded 

e.  Parameter  Problem 

f.  Timestamp  Reply 

g.  Information  Reply 
3.2.2  Transport  service 

3. 2. 2.1  Transport  service  shall  conform  to  the  requirements  of  the 
DoD  standard  Transmission  Control  Protocol  (TCP),  as  specified  in 
MIL-STD-1778. 


3.2. 2. 2  All  TCP  options,  as  specified  in  Section  6.2.11  of  MIL-STD- 
1778,  shall  be  implemented. 


3. 2. 2. 3  All  TCP  system  parameters  shall  be  settable. 

3. 2. 2. 4  Assignment  of  TCP  ports  shall  be  in  accordance  with  RFC  820, 
or  its  successor.  Specific  number  assignments,  when  required,  shall 
be  requested  from  the  DDN  PMO  Data  Base  and  Configuration  Management 
Branch,  Code  B628. 


3.3  Application  level  protocols 
|  3.3.1  Terminal-to-host  service 

3. 3. 1.1  Terminal-to-host  service  shall  conform  to  the  requirements  of 
the  TELNET  Protocol,  as  specified  in  the  document  entitled  "TELNET 
Protocol  Specification,"  RFC  854. 

3. 3. 1.2  As  a  minimum,  the  following  TELNET  options  shall  be  sup¬ 
ported: 

a.  Binary  Transmission,  as  specified  in  RFC  856, 

b.  Echo,  as  specified  in  RFC  857, 

c.  Suppress  Go  Ahead,  as  specified  in  RFC  858, 

d.  Status,  as  specified  in  RFC  859, 

e.  Timing  Mark,  as  specified  in  RFC  860,  and 

f.  Extended-Options-List,  as  specified  in  RFC  861. 

3 .3 .2  File  transfer  service 

3. 3. 2.1  File  transfer  service  shall  conform  to  the  requirements  of 
the  File  Transfer  Protocol,  as  specified  in  the  document  entitled 
"File  Transfer  Protocol,"  RFC  765. 

3.3. 2. 2  As  a  minimum,  servers  shall' implement  the  following  FTP  com¬ 
mands  : 

a.  user  name  (USER) 
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b.  password  (PASS) 

c.  logout  (QUIT) 

d.  data  port  (PORT) 

e.  passive  (PASV) 

f.  representation  type  (TYPE) 

g.  file  structure  (STRD) 

h.  transfer  node  (MODE) 

i.  retrieve  (RETR) 

j.  store  (STOR) 

k.  noop  (HOOP) 

3. 3. 2. 3  As  a  minimum,  ASCII  and  Image  data  representations  shall  be 
accepted. 

3. 3 .2. 4  All  references  to  mail  commands  including  the  Appendix  On 
Mail  shall  not  apply. 

3 .3 .3  Electronic  Mail  service 

3. 3 .3.1  Electronic  Mail  service  shall  conform  to  the  requirements  of 
the  Simple  Mail  Transfer  Protocol  (SMTP),  as  specified  in  the  docu¬ 
ment  entitled  "Simple  Mail  Transfer  Protocol,"  RFC  821. 

3.3 .3 .2  Specific  assignments  for  standard  names  for  links  and  proto¬ 
cols,  as  specified  in  Section  4.1.2  of  RFC  821,  shall  be  requested 
from  the  DDH  PMO  Data  Base  and  Configuration  Management  Branch,  Code 
B628. 


3.3 .3 .3  As  a  minimum,  receivers  shall  implement  the  SMTP  commands  as 
specified  in  Section  4.5.1  of  RFC  821. 


6.  TOTES 


6.1  Intended  use 

Connection  of  subscriber  devices  to  the  DDK  is  governed  by  the  inter¬ 
face  requirements  herein  (see  3.1).  Direct  host  connection  to  the 
DDN  (see  3.1.1  and  3.1.2)  and  the  provision  of  network  services 
within  a  subscriber  host  system  (see  3.2  and  3.3)  are  the  responsi¬ 
bilities  of  the  subscriber.  The  "of f“ loading"  of  the  host  level  pro¬ 
tocols  (see  3.2)  and  the  tezminal-to-host  service  (see  3.3.1)  may  be 
accomplished  by  using  standard  NAC  configurations. 


6.2  Terms  and  definitions 


Terms  and  definitions  pertaining  to  this  specification  are  contained 
in  FED— STD-1037 . 


6.3  Glossary 

ANSI 

ASCII 

ARPANET 

BBN 

CCITT 

DCE 

DDN 

DoD 

DoDISS 

DTE 

DTI 

EIA 

FIPS 

GPO 

HDH 

HDLC 

HFEP 

HFP 

HIP 

ICMP 

IMP 


-  American  National  Standards  Institute 

-  American  National  Standard  Code  for  Information 

Interchange 

-  Advanced  Research  Projects  Agency  Network 

-  Bolt  Beranek  and  Newman  Inc. 

-  International  Telegraph  and  Telephone  Consultative 

Committee 

-  Data  Circuit-terminating  Equipment 

-  Defense  Data  Network 

-  Department  of  Defense 

-  Department  of  Defense  Index  of  Specifications  and 

Standards 

-  Data  Terminal  Equipment 

-  Digital  Technology  Incorporated 

-  Electronic  Industries  Association 

-  Federal  Information  Processing  Standards 

-  Government  Printing  Office 

-  HDLC  Distant  Host 

-  High-level  Data  Link  Control 

-  Host  Front  End  Processor 

-  Host  Front-end  Protocol 

-  Host  to  IPLI  Protocol 

-  Internet  Control  Message  Protocol 

-  Interface  Message  Processor 
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IP 

- 

Internet  Protocol 

IPLI 

- 

Internet  Private  Line  Interface 

LAP  B 

- 

Link  Access  Procedures  (Balanced) 

mini-TAC 

- 

mini-Terminal  Access  Controller 

NAC 

- 

Network  Access  Component 

NIC 

- 

Network  Information  Center 

NPFC 

- 

Naval  Publications  and  Forms  Center 

N1IS 

- 

National  Technical  Information  Service 

PMO 

- 

Program  Management  Office 

RFC 

- 

Request  for  Comments 

SHIP 

- 

Simple  Mail  Transfer  Protocol 

TAC 

- 

Terminal  Access  Controller 

TBD 

- 

To  Be  Determined 

TCP 

- 

Transmission  Control  Protocol 

TEP 

- 

Terminal  Emulation  Processor 

WWMCCS 

- 

Worldwide  Military  Command  and  Control  System 

X.25 

- 

CCITT  protocol  standard 

READER’S  COMMENT  FORM 
DDN  Subscriber  Interface  Guide 


It  is  the  intent  of  the  Defense  Data  Network  Program  Management  Office  to 
support  subscribers  throughout  the  entire  process  of  transitioning  systems  to 
the  DDN.  This  Guide  has  been  prepared  to  assist  subscribers  in  one  phase  of 
that  process:  the  selection  and  acquisition  of  interfaces  for  connecting 
their  hosts  and  terminals  to  the  DDN. 

Comments  concerning  this  Guid*~  may  be  made  in  the  space  provided  below. 
Comments  on  the  following  topics  are  especially  solicited: 

1.  What  aspects  of  the  Guide  did  you  find  most  helpful? 

2.  What  additions,  deletions,  or  clarifications  would  make  this  Guide 
more  useful? 

3.  What  site-specific  problems  do  you  have  that  are  not  adequately 
addressed  in  this  Guide? 

Comments : 


Please  fill  in  the  requested  information. 

Position:  _ 

Name  (Optional) :  _ 

Address  (Optional) :  _ 

Status  of  your  system's  current  or  planned  DDN  connectivity: 


Thank  you  for  your  cooperation. 
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ERRATA  PAGES 


Subscriber  Interface  Specification 
(Appendix  A  of  Defense  Data  Network  Subscriber  Interface  Guide) 


Pedate  Sheet 

19  June  1984 


1.  Page  A-6,  line  14,  and  page  A-8,  line  1:  change  "X3. lb-197 9"  to 
"x3. 15-1976". 


2.  Page  A-6,  line  19,  and  page  A-8,  line  4:  change  "X3. 16-197 9"  to 
*X3. 16-197 6". 

3.  Page  A-6,  line  23,  and  page  A-7,  line  25:  change  "X3. 1-1979"  to 
X3. 1-1976". 


4.  Page  A-6,  lines  24  through  27:  delete. 


5.  Page  A-6,  line  29:  change  "IMT-FED-STD-1041"  to  "rED-STD-lu4l- 
PIPS  PUB  100". 


6.  Page  A-7:  insert  "MIL-8TD-188-114,  Electrical  Characteristics  of 
Digital  Interface  Circuits"  after  line  14. 


7.  Page  A-7:  insert  "MIL-STD-1780,  File  Transfer  Protocol",  "MIL- 
STD-1781,  Simple  Mail  Transfer  Protocol",  "MIL-STD-1782,  TELNET 
Protocol”  after  line  16. 


8.  Page  A-8:  insert  "EIA  K8-422-A,  Electrical  Characteristics  of 
Balanced  Voltage  Digital  Interface  Circuits",  "EIA  RS-423-A, 
Electrical  Characteristics  of  Unbalanced  Voltage  Digital 
Interface  Circuits"  after  line  12. 


9.  Page  A-8:  insert  "EIA  IEB  12,  Application  Notes  on  Inter¬ 
connection  Between  Interface  Circuits  Using  RS-449  and  BS-232-C" 
after  line  16. 
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10.  Page  A-8,  line  29:  delete. 


11.  Page  A-9,  line  3  and  line  4:  delete. 


12.  Page  A-9:  insert  "RFC  870,  Assigned  Numbers,  October  1983"  after 
line  6. 


13.  Page  A-9,  lines  7  through  13:  delete. 


14.  Page  A-9,  lines  21  through  24:  delete. 


15.  Page  A-10,  line  2:  change  "Corporation"  to  "Corporation, 
February  1984". 


16.  Page  A-10:  insert  "Defense  Data  Network  1.25  Host  Interface 
Specification,  Defense  Communications  Agency,  December  1983", 
"Interface  Message  Processor  -  Specifications  for  the 
Interconnection  of  a  Host  and  an  IMP,  Appendix  J  and  Appendix  K 
for  BBN  Report  No.  1822,  Bolt,  Beranek  and  Neman,  Inc., 
December  1983"  after  line  2. 


17.  Page  A-ll,  paragraphs  3. 1.1. 2.1,  3. 1.1. 2. 2:  delete.  Renumber 

3. 1.1. 2.3  to  3. 1.1. 2.2. 


18.  Page  A-ll:  insert  "3. 1.1. 2.1  The  physical  interface  shall 
conform  to  the  requirements  of  Appendix  J.2  of  the  document 
entitled,  INTERFACE  MESSAGE  PROCESSOR  -  Specifications  for  the 
Interconnection  of  a  Host  and  an  IMP,  BBN  Report  No.  1822". 
[Subscribers  should  select  the  interface  based  on  operational 
requirements,  coordinated  with  the  DDH  Program  Management  Office 
(PHD).] 


19.  Page  A- 12,  lines  7  through  10,  delete  "Subscribers  may  not 
implement  an  Z.25  interface  until  an  approved  DON  X.25 
specification  has  been  issued". 


20.  Page  A-12,  lines  14  through  16:  change  "the  document  entitled 
"INTERFACE  MESSAGE  PROCESSOR  -  Specifications  for  the 
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Interconnection  of  a  Host  and  an  IMP,  BBN  Report  No.  1822"  to 
read  "BBN  Report  No.  1822". 


21.  Page  A-12 ,  line  19:  change  "(RPC)  820"  to  "(RFC)  870". 


22.  Page  A-13,  line  2:  change  "Section  4.2  of  INT-FED-STD-1041"  to 
"FED-STD-1U41-— FIPS  PUB  100". 


23.  Page  A-13,  line  9:  change  "DM  Z.23  Specification,  to  be  iasued 
in  a  revision  to  this  specification."  to  "Defense  Data  Network 
X.25  Host  Interface  Specification". 


24.  Page  A- 14,  line  5:  change  IkIC  820"  to  "RPC  870". 


25.  Page  A- 14,  line  17:  change  "Section  4.2  of  INT-FED-STD-1041"  to 
"PED-STD-1041— FIPS  PUB  100". 


26.  Page  A-13,  line  3:  change  "PED-STD-1031 .  The  provisions  of 
Section  6.C  shall  apply"  to  "EIA  RS-449,  Category  I  circuits 
shall  iaplcnent  EIA  RS-422-A  as  prescribed  in  Section  6.11  of 
RS-449.  The  additional  provisions  of  MIL-STD-188-114  shall 
apply". 


27.  Page  A-15,  line  5:  change  "those  designated  0  (optional)  in 
Table  7  of  BBN  Report  No.  5224  shall  be  inpleaented"  to  "Test 
Mode  (TM)  and  those  designated  "A"  or  "0"  in  Figure  5.1  of  EIA 
RS-449  shall  be  iupleaented". 


28.  Page  A-15,  line  24:  change  "8ection  4.2  of  INT-FED-STD-1041 "  to 
"PED-STD-1041  —PIPS  PUB  100". 


29.  Page  A-16,  line  8:  change  "FED-STD-1031"  to  "EIA  RS-449". 


30.  Page  A-16,  line  9:  change  "the  provisions  of  Section  6.A  shall 
apply."  to  "generators  on  all  Category  I  circuits  shall  conform 
to  EIA  RS-423-A  and  the  provisions  described  in  EIA  IBB  12  shall 
be  act*. 
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31.  Page  A-16,  lines  10  through  12:  change  "the  provisions  of 

Section  6.B  shall  apply.  For  all  other  interfaces,  the 

provision  of  Section  6.C  shall  apply"  to  "generators  on  all 
Category  I  circuits  shall  conform  to  EZA  RS-423A  (MIL-STD-188- 
114  unbalanced  circuits)  and  shall  have  an  option  which  will 
allow  changing  the  signal  sense  from  the  negative  mark  to 

positive  mark.  For  all  other  interfaces,  all  provisions  of  EIA 
RS-449  shall  apply.  Category  I  circuits  may  implement  either 
EIA  RS-422-A  or  EIA  RS-423-A  as  prescribed  in  Section  6.11  of 
EIA  RS-449.  When  EIA  RS-422-A  is  employed  for  MIL-STD-188 
applications,  the  additional  provisions  of  MIL-STD-I88-114  shall 
apply". 


32.  Page  lb,  lines  13-16:  change  "those  designated  0  (optional)  in 
Table  7  of  BBN  Report  Ho.  5224"  to  "Test  Mode  (TM)  and  those 
designated  "A"  or  "0"  in  Figure  5.1  of  EIA  RS-449". 


33.  Page  16,  line  22:  change  "9400"  to  "9600”. 


34.  Page  A-18,  line  3:  change  "FED-STD-1031"  to  "EIA  RS-449". 


35.  Page  A-18,  line  3:  change  "For  all  terminals  conforming  to  EIA 
RS-232-C,  the  provisions  of  Section  6.A  shall  apply.  For  all 
terminals  conforming  to  MIL-STD-188C  or  MI L-STD-1 88-100,  the 
provisions  of  Section  6.B  shall  apply.  For  all  other  terminals, 
the  provisions  of  Section  6.C  shall  apply."  to  "for  all 
interfaces  conforming  to  EIA  RS-232-C,  generators  on  all 
Category  I  circuits  shall  conform  to  EIA  RS-423-A  and  the 
provisions  described  in  XEB  12  shall  be  met.  For  all  interfaces 
conforming  to  MIL-8TD-188C  or  MIL-8TD-188-100 ,  generators  on  all 
Category  I  circuits  shall  conform  to  EIA  RS-423-A  (MIL-STD-188- 
114  unbalanced  circuits)  and  shall  have  an  option  that  will 
allow  changing  the  signal  sense  from  the  negative  mark  to 
positive  mark.  For  all  other  interfaces,  all  provisions  of  EIA 
RS-449  shall  apply.  Category  I  circuits  may  implement  either 
EIA  IS-422ri  or  EIA  RS-423-A  as  prescribed  in  Section  6.11  of 
EIA  RS-449.  When  EIA  RS-422A  is  employed  for  MIL- STD- 188 
applications,  the  additional  provisions  of  MIL-8TD-188-114  shall 
apply”. 


36.  Page  A-18,  line  10:  change  "those  designated  0  (optional)  in 
Table  7  of  BBR  Report  lo.  5224"  to  *Test  Mode  (W)  and  those 
designated  "A"  or  "0"  in  Figure  5.1  of  EIA  RS-449”. 
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37.  Page  A-19,  lines  1  tluough  3,  delete 


38*  Page  A-19,  line  18:  change  "The  maximum"  to  "The  default 
maximum" * 


39.  Page  A-19,  line  22:  change  "RFC  820"  to  "RFC  870". 


40.  Page  A-21,  line  2:  change  "RPC  820"  to  "RPC  870". 


41.  Page  A-21,  line  9:  change  "the  document  entitled  "TELNET 
Protocol  Specification,  "RPC  854."  to  "MIL-STD-1782". 


42.  Page  A-21,  paragraph  3. 3. 1.2,  delete. 


43.  Page  A-21:  insert  "3. 3. 1.2  As  a  minimum,  the  DoD  approved  TELNET 
options,  as  specified  in  the  appendices  to  MIL-STD-1782,  shall 
be  supported." 


44.  Page  A-21,  lines  21-22:  change  "the  document  entitled  "File 
Transfer  Protocol,"  RPC  765."  to  "MIL-STD-1780". 


45.  Page  A-21,  paragraph  3. 3. 2. 2,  delete. 


46.  Page  A-21:  insert  "3 .3. 2. 2  As  a  minimum,  servers  shall  implement 
the  FTP  commands  specified  in  Section  5.9.1  of  MIL-STD-1780.", 
after  line  22. 


47.  Page  A- 22,  lines  17-18:  change  "the  docusmnt  entitled  "Simple 
Mail  Transfer  Protocol",  RFC  821."  to  "MIL-8TD-1781". 


48.  Page  A-22,  line  20:  change  "Section  4.1.2  of  RFC  821"  to 
"Section  6. 1.3.3  of  MIL- STD-17 81". 


49.  Page  A-22,  line  24:  change  "Section  4.5.1  of  RFC  821"  to 
"Section  6.5.1  of  MXL-8TD-1781". 
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